前三天提到的Power Automate工具應用主要針對一些日常行為的自動化，或者是流程中需要搭配各式各樣的第三方服務，而接下來的第二個case會從比較系統面和可能延伸的應用做評估。

需求的發生以及對應可以處理的方案

情境闡述

此案例的為例行人員檢查完存取填寫紀錄的系統，現況以及當前希望的需求透過以下幾點說明。

• 現況是透過表單的相關服務或者是excel的方式存取，但當要做一段時間的報表回顧會耗費較多時間彙整
• 填寫的過程中沒有驗證的機制
• 過往沒有相關性質的系統可以參考
• 有時程上的壓力並且希望能夠整合現有的相關登入機制(ex : 透過已經開好的OA帳號登入)
• 部分填寫人員已經熟悉現有的流程，如果系統做大幅度的改版對於他們而言較耗費時間學習
• 期望能夠透過一個平台延伸管理未來相同性質的需求

上述幾點的項目主要以較重要的部分提出，撇除需求者其他額外的想法或者是其他不可抗拒的因素，接著來進一步思考可以使用那些方案處理。

時程的壓力利刃

由於這個需求有時程上的上線壓力，並且扣除討論需求和相關的確認後的開發時間，約莫一個多月可以做這件事情，所以個人會傾向先尋找可以滿足大部分需求的工具或是服務。

開發能力很厲害我可以自己做就好了啊!

而在評估的過程中其實腦海都會迴盪上面的那一句話，但由於評估過程中沒有相同性質已經上線的系統可以參考，並且若要一直延伸相關的需求，在時程壓力下開發出來的功能雖然能夠滿足使用者，但在技術債以及後續維護上的困難度已已經默默的在累積了。

而到最後的方案比較最後選擇了Jira + Web Api的開發方式做為這個情境的解決方案，而在加值應用的部分則使用Confluecne，至於先說明為什麼會用Jira + Web Api這個方案解決原因點有以下幾項。

• 因需求的系統定位是紀錄填寫與管理正好切合Jira對於Task的相關應用
• 驗證的機制當逐漸複雜時，Jira可以搭配第三方的外掛套件純程式的方式滿足
• 相關的登入機制在Jira的system就可以做一些相關的設定
• 直接使用一套成熟的產品可以直接從現有的功能進行開發和設計
• 後續有新的專案時在Jira可以直接做建立的動作，並且流程或者是欄位可以參考現有的其他專案
• 驗證的相關資訊若源自於其他系統時可以再獨立開發API做為資料交換的媒介

講到這個部分的時候看到Web Api會想說啊還不是要純程式開發，確實是這樣但純程式開發的功能並不是整個專案的主體，而是要解決資料交換間的安全性與擴充性。

如果還不清楚Jira是什麼工具的話可以參考第七天的文章，而接下來則會依照今天提到的相關資訊進一步說明實際應用的做法。